FivetranだけでSlowly Changing Dimensionsが実現できる！History Modeを使ってみた
大阪オフィスの玉井です。
今回は、「すぐONにできるけど、実際にONにするとどうなるかよくわからない」機能であるHistory Modeについて説明します。
History Modeとは
Fivetranの機能に「History Mode」というものがあります。Connectorの設定画面で、連携するテーブル（オブジェクト）やカラムを選択できるメニューで、連携方式を通常のものかHistory Modeか選ぶことができます。
History Modeを選ぶと、何が起こるのでしょうか。
簡単にいうと…
Slowly Changing Dimensionsのタイプ2をFivetranで行うことができます。
…
…
…は？？？
もう少し説明
Slowly Changing Dimensions（SCD）とは
データ分析をする人にとっては当たり前の概念ですが、データウェアハウスにおいて、ディメンションというものがあります。データを分析する際に切り口となるデータのことです。日付、商品カテゴリ、顧客住所など、組織によって色々なディメンションがあると思います。
そのディメンションですが、当然、未来永劫同じ値ではあるとは限りません。例えば、ECサイトの顧客の住所データは、その顧客が引っ越しして住所変更を行った時点で値が変わります。この時、何も考えず、テキトーに住所データを上書きしてしまうと、その顧客がこれまで行った購買は、データ上、全て引越し後の住所から注文したことになってしまいます。このように、ディメンションは、頻繁には変わりませんが、あるタイミングで別の値に移り変わっていきます（だからSlowly Changing）。
実は、ディメンションデータの移り変わりに対して、更新をどう管理していくかというのは、そこそこ昔から方法論が確立されています。これを「Slowly Changing Dimensions」といいます。詳細や歴史等は、検索するとたくさん出てくるので、興味のある方は調べてみてください。
Slowly Changing Dimensionsにはタイプ1〜6がありますが、FivetranのHistory Modeでできるのは、タイプ2です。
Type 2
簡単に説明すると、変更履歴をデータ上にしっかり残す方式です。データが変わった時、変わる前のデータは削除せずに、フラグを立てて、残しておきます。そして、変更後のデータは、新しいデータとして追加します。時間も記録しておくため、「このディメンションのこの値がアクティブだった時間（日付）」もわかるようになります。
全て記録するので、分析等に便利な反面、DWH側の容量を食うのがデメリットです。
実際にやってみる
環境
- Fivetran
- Connector：Salesforce
- Destination：BigQuery
Fivetran側でHistory ModeをONにする
今回はUserというオブジェクトを対象にします。GUIメニューでHistory Modeを有効化します。
注意書きのポップアップが出てきます。ここに書かれている内容については後で説明します。
同期後、データを確認する
History Modeを有効化した後、同期を行います。すると、有効化したオブジェクトであるUserテーブルに新しいカラムが3つ追加されました。
先程の注意書きにもあった通り、History ModeをONにしたテーブルには、この3つのカラムが追加されます。
_fivetran_start- そのレコードが最新だった期間のスタート
_fivetran_end- そのレコードが最新だった期間のエンド
_fivetran_active- そのレコードが最新であるかどうか
前述したように、SCD Type 2では、そのディメンションの変更前のデータも残しておく（つまり削除という概念がなくなる）ため、_fivetran_deletedというカラムは使われなくなります。
データソース側でデータに変更を加える
History Modeを有効化したところで、さっそくデータソース側に変更を加えてみましょう。Saleforce側で、ユーザー情報を変更してみます。
Fivetranで再度同期を行い、データを確認する
Saleforceのユーザー情報を変更後、再度Fivetranで同期を行い、データを確認してみます。
同じデータであるはずのtamaiというユーザーが2レコードありますね。しかし、先程更新した住所情報が反映されているのは、後から追加された方のレコードのみです。
History Modeで追加されたカラムを確認すると、以前から存在する方の_fivetran_activeはfalse、新しく追加されたレコードはTrueとなっています。これは住所情報を変更した後のレコードが正である（現時点での最新である）ことを示します。
また、旧レコードの方の_fivetran_endには、データが変更された時間が記録されています。対して、新レコードの方の_fivetran_startにも、変更された時間が記録されています。これを利用すれば、特定の時期のディメンションの値を指定しつつデータ分析ができますね。
考慮事項など
分析の幅が広がる
例えば、Saleforceの商談情報をHistory Modeで追跡すると、1つ1つの商談のフェーズの移り変わりを分析することができます。どういうタイミングでフェーズが進むのか、フェーズが変わるタイミングの決め手は何が多いのか、などがわかるかもしれません。
ポイントプログラムの顧客データを追跡すれば、各顧客がどういう頻度でポイントを貯めていってて、どの程度がどういう時期に会員ランクが上がっているのか、ということを分析できそうです。
Slowly Changing Dimensionsの運用を丸投げできる
見落としがちなメリットなのですが、SCDという仕組みをイチから実装しようとすると、運用含めて、結構骨が折れると思います。それをFivetranに丸投げできるのは、かなり大きいでしょう。
気をつけたい点
レコードの変更が行われる度に、新レコードが増えるため、DWH側のデータ量が増えます。しかし、それより大事なのは、FivetranのMARが結構増えるということです。純粋にFivetranの課金が上がるため、利用は計画的に行う必要があります。
また、BIツールを利用している場合、既存ダッシュボードには「_fivetran_activeがTrueのものだけを引っ張る」みたいな条件を入れる必要が出てくるかもしれません。
おわりに
コストは上がってしまいますが、ビジネスの成長につながる分析ができるようになる機能だと思います。お試しあれ。
